Relational Database Design and Modeling for Software Engineers
Rate this course
Ask Author
Contribute
Back to course home

0% completed

Vote For New Content
Introduction
Course Overview
Before the Advent of Database
Fundamental Concepts
What is a Database?
Database management systems (DBMS)
Overview of Relational Databases
Relational Vs. Non-Relational Databases
Data Modeling
Introduction to Data Modeling
Levels of Data Modeling
Data Modeling Process
Best Practices in Data Modeling
Quiz
Entity-Relationship (ER) Data Modeling
Introduction to ER Models
Entities, Attributes, and Relationships
Cardinality and Participation
Attributes of Relationship Types
Weak Entity Types
Creating an ER Diagram for Employee Management System
Quiz
The Relational Data Model
Introduction to the Relational Model
Relations, Tuples, and Attributes
Keys in Relational Databases
Relational Integrity Constraints
Converting ER Diagrams to Relational Model
Best Practices for ER Diagrams to Relational Models
Quiz
Functional Dependency
Introduction to Functional Dependency
Types of Functional Dependencies
Inference Rules for Functional Dependencies
Closure of Attribute Sets
Quiz
Introduction to Normalization
First Normal Form (1NF)
Second Normal Form (2NF)
Third Normal Form (3NF)
Boyce-Codd Normal Form (BCNF)
Higher Normal Forms (4NF, 5NF)
Exercise 1
Solution to Exercise 1
Exercise 2
Solution to Exercise 2
Designing a Hospital Management System
Designing a Hotel Management System
Designing a Bank Management System
Designing an Instagram
Designing an E-commerce Platform
Designing an Online Food Delivery System
Inference Rules for Functional Dependencies

Inference rules, also known as Armstrong’s Axioms, are foundational rules used to derive all possible functional dependencies from a given set of dependencies in a relational database. These rules—Reflexivity, Augmentation, and Transitivity—are essential for understanding and organizing functional dependencies effectively, which aids in database normalization and minimizes redundancy.

Image

Let’s go through these three main rules with examples and tables based on a Student database.

1. Reflexivity Rule

The Reflexivity Rule states that if a set of attributes Y is a subset of a set of attributes X, then X → Y holds. This means an attribute or a combination of attributes always determines itself or any subset of itself.

  • Notation: If Y ⊆ X, then X → Y.

  • Example: Consider the following Student table with attributes {Student_ID, Name, Course}.

Student_IDNameCourse
101Alice SmithMath
102Bob JohnsonScience
103Carol WhiteHistory

In this table:

  • {Student_ID, Name} → Student_ID is a valid dependency because Student_ID is a subset of {Student_ID, Name}.
  • {Student_ID, Course} → Course also holds by reflexivity, as Course is a subset of {Student_ID, Course}.

The reflexivity rule emphasizes that any attribute set inherently determines itself and any subset of its components.

2. Augmentation Rule

The Augmentation Rule states that if X → Y holds, then adding an attribute Z to both sides of the dependency will still result in a valid dependency. This rule allows attributes to be added to a dependency without altering its validity.

  • Notation: If X → Y, then XZ → YZ (where XZ is the union of X and Z).

  • Example: Using the same Student table above, suppose we know that Student_ID → Name holds true, meaning that each Student_ID uniquely identifies a Name.

Now, let’s add Course to both sides:

  • {Student_ID, Course} → {Name, Course} also holds by the augmentation rule. If we know that Student_ID determines Name, then {Student_ID, Course} will still uniquely determine both Name and Course.

This rule is especially useful when constructing complex dependencies that involve multiple attributes while ensuring no loss of information.

3. Transitivity Rule

The Transitivity Rule is similar to the transitive property in mathematics. It states that if X → Y and Y → Z hold, then X → Z is also a valid dependency. Transitivity is crucial for identifying indirect dependencies that can contribute to redundancy if not properly managed.

  • Notation: If X → Y and Y → Z, then X → Z.

  • Example: Consider an expanded Student_Department table with the following attributes:

Student_IDDepartment_IDDepartment_Name
101D01Science
102D02Arts
103D03Commerce

In this table, suppose the following dependencies hold:

  • Student_ID → Department_ID: Each student is assigned a unique department.
  • Department_ID → Department_Name: Each department ID uniquely identifies a department name.

By the transitivity rule:

  • Student_ID → Department_Name can be inferred, meaning Student_ID indirectly determines Department_Name through Department_ID.

This transitive dependency highlights the need to normalize data to reduce redundancy, as it indicates that storing Department_Name with Student_ID could result in unnecessary data duplication.

Summary Table of Inference Rules

RuleDefinitionExample
ReflexivityIf Y is a subset of X, then X → Y{Student_ID, Name} → Student_ID
AugmentationIf X → Y, then XZ → YZIf Student_ID → Name, then {Student_ID, Course} → {Name, Course}
TransitivityIf X → Y and Y → Z, then X → ZIf Student_ID → Department_ID and Department_ID → Department_Name, then Student_ID → Department_Name
Types of Functional Dependencies
Closure of Attribute Sets
Mark as Completed

On this page

  1. Reflexivity Rule
  1. Augmentation Rule
  1. Transitivity Rule

Summary Table of Inference Rules